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Abstract 


This  paper  discusses  the  synchronization  issues  that  arise  when  transaction  facilities  arc  extended  for  use  with 
shared  abstract  data  types.  A  formalism  for  specifying  the  concurrency  properties  of  such  types  is  developed, 
based  on  dependency  relations  that  arc  defined  in  terms  of  an  abstract  type’s  operations.  The  formalism 
requires  that  the  specification  of  an  abstract  type  state  whether  or  not  cycles  involving  these  relations  should 
be  allowed  to  form.  Directories  and  two  types  of  queues  arc  specified  using  the  technique,  and  the  degree  to 
which  concurrency  is  restricted  by  type-specific  properties  is  exemplified.  The  paper  also  discusses  how  the 
specifications  of  types  interact  to  determine  the  behavior  of  transactions.  A  locking  technique  is  described 
that  permits  implementations  to  make  use  of  type-specific  information  to  approach  the  limits  of  concurrency. 


Copyright  ©  1983  Peter  M.  Schwarz  and  Alfred  Z.  Speetor, 

Technical  Report  CMU-CS-83-163,  Revision  ofCMU-CS-82-128 

This  research  was  sponsored  by:  the  USAF  Rome  Air  Development  Center  under  contract  F30602-81- 
C-0297:  the  US  Naval  Ocean  Systems  Center  under  contract  number  N66001-81-C-04S4  N65;  and  the 
Defense  Advanced  Research  Projects  Agency  (DOD),  ARPA  Order  No.  3597,  monitored  by  the  Air  Force 
Avionics  Laboratory  Under  Contract  F33615-81-K-1539. 

The  views  and  conclusions  contained  in  this  document  arc  those  of  the  authors  and  should  not  be 
interpreted  as  representing  the  official  policies,  either  expressed  or  implied,  of  the  Defense  Advanced 
Research  Projects  Agency  or  the  US  Government. 


90  05  14  108 


1 


Table  of  Contents 

1  Introduction  1 

2  Background  2 

3  Dependencies:  A  Tool  for  Reasoning  About  Concurrent  Transactions  4 

3.1  Schedules  4 

3.2  Dependencies  and  Consistency  5 

3.3  Dependencies  and  Cascading  Aborts  8 

4  Specification  of  Shared  Abstract  Types  8 

4.1  Directories  10 

4.2  FIFO  Queues  13 

4.3  Queues  Allowing  Greater  Concurrency  15 

4.4  Proving  the  Correctness  of  Type  Implementations  17 

5  Ordcrability  of  Groups  of  Transactions  18 

5.1  How  die  Specifications  of  Multiple  Types  Interact  19 

5.2  Correctness  of  Transactions  20 

6  A  Technique  for  Synchronizing  Shared  Abstract  '1  ^pes  21 

6.1  Type-Specific  Locking  21 

6.2  Directories  23 

6.3  Strictly  FIFO  Queues  25 

6.4  WQucucs  26 

6.5  Summary  27 

7  Summary'  28 

8  Acknowledgments  29 


1 


1  Introduction 

Transactions  facilities,  as  provided  in  many  database  systems,  permit  the  definition  of  Iran. sac  I  ions 
containing  operations  that  read  and  write  the  database  and  that  interact  with  die  external  world.  The 
transaction  facility  of  the  database  system  guarantees  that  each  invocation  of  a  transaction  will  execute  at  most 
once  (i.c.,  either  commit  or  abort)  and  will  be  isolated  from  the  deleterious  effects  of  all  concurrently 
executing  transactions.  To  make  these  guarantees,  the  transaction  facility  manages  transaction 
synchronization,  recovery,  and,  if  necessary,  inter-site  coordination.  Many  papers  have  been  written  about 
transactions  in  the  context  of  both  distributed  and  non-distributed  databases  [Bernstein  81,  Hswaran  76,  Gray 
80,  I  nmpson  81  Lindsay  7Q], 

There  are  a  number  of  ways  in  which  transaction  facilities  could  be  extended  to  simplify  the  construction  of 
many  types  of  reliable  distributed  programs,  Hxtcnsions  that  allow  a  wider  variety  of  operations  to  be 
included  in  a  transaction  would  facilitate  manipulation  of  shared  objects  other  than  a  database.  Hxtcnsions 
that  permit  transaction  nesting  would  facilitate  more  flexible  program  organizations,  as  would  extensions 
allowing  some  form  of  inter-transaction  communication  of  uncommitted  data.  Although  the  synchronization, 
recovery,  and  inter-site  coordination  mechanisms  needed  to  support  database  transaction  facilities  arc 
reasonably  well  understood,  diese  mechanisms  require  substantial  modification  to  support  such  extensions. 
For  example,  drey  must  be  made  compatible  with  the  abstract  data  type  model  and  with  general 
implementation  techniques  such  as  dynamic  storage  allocation. 

Lomct  [Lomct  77]  considered  some  of  die  problems  encountered  in  developing  general-purpose  transaction 
facilities,  but  more  recently,  much  of  the  research  in  this  area  has  been  done  at  MIT.  Moss  and  Reed  have 
discussed  nested  transactions  and  other  relate  -  vvmms  issues  [Moss  81,  Reed  78],  As  part  of  the  Argus 
project,  extensions  to  CLU  have  been  propose,  d  incorporate  primitives  for  supporting  transactions 
[Liskov  82a,  Liskov  82b],  Additionally,  Weihl  has  considered  transactions  that  contain  calls  on  shared 
abstract  types  such  as  sets  and  message  queues,  and  has  discussed  their  implementation  [Weihl  83a,  Weihl 
83b],  Transactions  will  also  be  available  in  the  Clouds  distributed  operating  system  [Allchin  83]. 

This  paper  focuses  on  one  important  issue  that  arises  when  extending  transaction  facilities:  the 
synchronization  of  operations  on  shared  abstract  data  types  such  as  directories,  stacks,  and  queues.  After  a 
presentation  of  background  material  in  the  following  section,  Section  3  introduces  some  tools  and  notation  for 
specifying  shared  abstract  types.  Section  4  describes  three  particular  data  types  and  uses  the  tools  to  specify 
how  operations  on  these  types  can  interact  under  conditions  of  concurrent  access  by  multiple  transactions. 
The  specifications  that  are  developed  make  explicit  use  of  type-specific  properties,  and  it  is  shown  how  this 
approach  permits  greater  concurrency  than  standard  techniques  that  do  not  use  such  information.  Section 
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5  discusses  how  die  specifications  of  individual  types  interact  to  determine  global  properties  of  groups  of 
transactions.  Section  ft  proposes  an  extensible  approach  to  locking  dial  can  be  used  for  synchronization  in 
implementations  intended  to  meet  diese  specifications.  Finally.  Section  7  summarizes  die  major  points  of  diis 
paper  and  concludes  with  a  brief  discussion  of  other  considerations  in  die  implementation  of  user-defined, 
shared  abstract  data  types. 

2  Background 

Transactions  aid  in  maintaining  arbitrary  application-dependent  consistency  constraints  on  stored  data.  The 
constraints  must  be  maintained  despite  failures  and  widiout  unnecessarily  restricting  the  concurrent 
processing  of  application  requests. 

In  die  database  literature,  transactions  are  defined  as  arbitrary  collections  of  database  operations  bracketed 
by  two  markers:  BeginTtansaciion  and  EndTransaclion.  A  transaction  that  completes  successfully  commits', 
an  incomplete  transaction  can  terminate  unsuccessfully  at  any  time  by  aborting.  Transactions  have  the 
following  special  properties: 

1.  Either  all  or  none  of  a  transaction's  operations  are  performed.  This  property  is  usually  called 
failure  atomicity. 

2.  If  a  transaction  completes  successfully,  the  effects  of  its  operations  will  never  subsequently  be  lost. 

This  property  is  usually  called  permanence. 

3.  If  a  transaction  aborts,  no  other  transactions  will  be  forced  to  abort  as  a  consequence.  Cascading 
aborts  are  not  permitted. 

4.  If  several  transactions  execute  concurrently,  they  affect  the  database  as  if  they  were  executed 
serially  in  some  order.  This  property  is  usually  called  serializabilily. 

Transactions  lessen  the  burden  on  application  programmers  by  simplifying  the  treatment  of  failures  and 
concurrency.  Failure  atomicity  makes  certain  that  when  a  transaction  is  interrupted  by  a  failure,  its  partial 
results  are  undone.  Programmers  are  therefore  free  to  violate  consistency  constraints  temporarily  during  the 
execution  of  a  transaction.  Serializability  ensures  that  other  concurrently  executing  transactions  cannot 
observe  these  inconsistencies.  Permanence  and  prevention  of  cascading  aborts  limit  the  amount  of  effort 
required  to  recover  from  a  failure.  Transaction  models  that  do  not  prohibit  cascading  aborts  are  possible,  but 
we  do  not  consider  them. 

Our  model  for  using  transactions  in  distributed  systems  differs  from  this  traditional  model  in  several  ways. 
The  most  important  difference  is  that  we  incorporate  the  concept  of  an  abstract  data  type.  That  is, 
information  is  stored  in  typed  objects  and  manipulated  only  by  operations  that  are  specific  to  a  particular 
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object  upc.  The  users  of  a  type  arc  given  a  specification  that  describes  the  effect  of  each  operation  on  the 
stored  data,  u”d  new  abstract  types  can  be  implemented  using  existing  ones.  T  he  details  of  how  objects  arc 
represented  and  how  the  operations  arc  carried  out  are  known  only  to  a  type's  implementor.  Abstract  data 
types  grew  our  of  die  class  construct  in  Simula  [Dahl  72],  and  are  supported  in  many  other  programming 
languages  including  Cl.U[I.iskov  77],  Alphard  [Wtilf  76],  and  Ada  [Dept,  of  Defense  82],  as  well  as  in 
operating  systems,  e.g.  Hydra  [Wulf  74],  In  our  system  model,  transactions  arc  composed  of  operations  on 
objects  that  arc  instances  of  abstract  types.  Of  particular  interest  arc  those  objects  that  arc  not  local  to  a  single 
transaction.  These  arc  instances  of  shared  abstract  types. 

We  assume  that  the  facilities  for  implementing  shared  abstract  types  and  for  coordinating  the  exce  dien  of 
transactions  that  operate  on  them  arc  provided  by  a  basic  system  layer  chat  executes  at  each  node  of  the 
system.  This  transaction  kernel  exports  primitives  for  synchronization,  recovery,  deadlock  management,  and 
inter-site  communication.  In  some  ways,  a  transaction  kernel  is  similar  to  the  RSS  of  System  R  [Gray  81].  A 
transaction  kernel,  however,  is  intended  to  run  on  a  bare  machine  and  must  supply  primitives  useful  for 
implementing  arbitrary  data  types,  whereas  the  RSS  has  the  assistance  of  an  underlying  operating  system  and 
only  provides  specialized  primitives  tailored  for  manipulating  a  database. 

Another  difference  between  our  system  model  and  the  traditional  transaction  model  is  that  we  do  not 
necessarily  require  that  transactions  appear  to  execute  serially.  Scrinlizability  ensures  that  if  transactions  work 
correctly  in  the  absence  of  concurrency,  any  interleaving  of  their  operations  that  is  allowed  by  the  system  will 
not  affect  their  correctness.  Hut  sometimes,  scrializability  is  too  strong  a  property,  and  requiring  it  restricts 
concurrency  unnecessarily.  For  example,  it  is  usually  unnecessary  for  two  letters  mailed  together  and 
addressed  identically  to  appear  in  their  recipient's  mailbox  together.  However,  scrializability  is  violated  if  the 
letters  do  not  arrive  contiguously,  because  there  is  no  longer  the  appearance  that  the  sender  has  executed 
without  interference  from  other  senders.  Thus,  it  may  be  desirable  for  some  shared  abstract  types  to  allow 
limited  non-serializablc  execution  of  transactions.  This  idea  has  also  been  investigated  by  Garcia-Molina 
[Garcia-Molina  83]  and  Sha  ct  al.  [Sha  83]. 

Scrializability  guarantees  that  an  ordering  can  be  defined  on  a  group  of  transactions.  If  the  transactions 
share  some  common  objects,  scrializability  requires  that  these  objects  be  visited  in  the  same  order  by  all  the 
transactions  in  the  group.  In  the  next  section,  a  more  general  ordering  property  of  transactions  is  defined,  of 
which  scrializability  is  a  special  ease.  We  will  show  that  it  is  possible  to  prove  that  transactions  work  correctly 
in  the  presence  of  concurrency,  even  if  they  do  not  appear  to  execute  serially. 

In  order  to  maintain  the  special  properties  of  transactions  in  our  model,  the  operations  on  shared  abstract 
types  that  compose  them  must  meet  certain  requirements.  To  guarantee  the  failure  atomicity  of  transactions, 
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it  must  be  possible  to  undo  any  operation  upon  transaction  abort.  Therefore,  an  undo  operation  must  be 
provided  for  each  operation  on  a  shared  abstract  type.  Recovery  is  not  the  main  concern  of  this  paper,  and  we 
will  be  considering  undo  operations  only  as  they  pertain  to  synchronization  issues.  Further  discussion  of 
recovery  issues  can  be  found  in  a  related  paper  [Schwarz  83]. 

Operations  on  shared  abstract  types  must  also  meet  three  synchronization  requirements: 

1.  Operations  must  be  protected  from  anomalies  that  could  be  caused  by  other  concurrently 
executing  operations  on  the  same  object.  Freedom  from  these  concurrency  anomalies  ensures  that 
an  invocation  of  an  operation  on  a  shared  object  is  not  affected  by  other  concurrent  operation 
invocations.  This  is  die  same  property  that  monitors  provide  [Hoare  74]. 

2.  To  preclude  the  possibility  of  cascading  aborts,  operations  on  shared  objects  must  not  be  able  to 
observe  information  that  might  change  if  an  uncommitted  transaction  were  to  abort.  This  may 
necessitate  delaying  die  execution  of  operations  on  behalf  of  some  transactions  until  other 
transactions  complete,  eidicr  successfully  or  unsuccessfully. 

3.  When  a  group  of  transactions  invokes  operations  on  shared  objects,  the  operations  may  only  be 
interleaved  in  ways  diat  preserve  scrializability  or  some  weaker  ordering  property  of  the  group  of 
transactions.  The  synchronizahon  needed  to  control  interleaving  cannot  be  localized  to  individual 
shared  objects,  but  rather  requires  cooperation  among  all  the  objects  shared  by  the  transactions. 

Traditional  methods  for  synchronizing  access  to  an  instance  of  a  shared  abstract  type  arc  designed  solely  to 
ensure  the  first  goal:  correctness  of  individual  operations  on  an  object.  This  paper  is  concerned  with  the 
second  and  diird  goals.  We  examine  the  problem  of  specifying  the  synchronization  needed  to  achieve  diem, 
as  well  as  the  support  facilities  that  the  transaction  kernel  must  provide  to  implementors  of  shared  abstract 
types. 

3  Dependencies:  A  Tool  for  Reasoning  About  Concurrent  Transactions 

This  section  intr  oduces  a  theory  that  can  be  used  to  reason  about  die  behavior  of  concurrent  transactions.  It 
allows  die  standard  definition  of  scrializability  to  be  recast  in  terms  of  shared  abstract  types,  and  provides  a 
convenient  way  of  expressing  other  ordering  properties.  The  dicory  is  also  useful  in  understanding  cascading 
aborts. 

3.1  Schedules 

Schedules  [Eswaran  76,  Gray  75]  can  be  used  to  model  the  behavior  of  a  group  of  concurrent  transactions. 
Informally,  a  schedule  is  a  sequence  of  transaction,  operation)  pairs  that  represents  the  order  in  which  the 
component  operations  of  concurrent  transactions  are  interleaved.  Schedules  are  also  known  as 
Ais/or/es  [Papadimitriou  77]  and  fogs  [Bernstein  79].  In  some  of  the  traditional  database  literature,  the 
operations  in  schedules  arc  assumed  to  be  arbitrary;  no  semantic  knov/ledgc  about  them  is  available  [Eswaran 
76].  In  this  ease,  a  schedule  is  merely  an  ordered  list  of  transactions  and  the  objects  they  touch: 
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In  other  work,  operations  are  characterized  as  Rcad(R)  or  Writc(W)  [Gray  75],  in  which  case  the  schedule 
includes  that  semantic  information: 

V  R(°i) 

v  R(°i) 

V  w(°2) 
v  R(02) 


To  analyze  transactions  that  contain  operations  on  specific  shared  abstract  types,  we  will  consider  schedules 
in  which  these  operations  arc  characterized  explicitly.  For  example,  a  schedule  may  contain  operations  to 
enter  an  element  on  a  queue  or  to  insert  an  entry  into  a  directory.  We  call  these  abslraci  schedules,  because 
they  describe  the  order  in  which  operations  affect  objects,  regardless  of  any  reordering  that  might  be  done  by 
their  implementation.1  Given  the  initial  state  of  a  set  of  objects,  an  abstract  schedule  of  operations  on  these 
objects,  and  specifications  for  the  operations  in  the  schedule,  the  result  of  each  operation  and  the  final  state  of 
the  objects  can  be  deduced.  For  instance,  consider  die  following  abstract  schedule,  which  is  composed  of 
operations  on  Q,  a  shared  object  of  type  FIFO  Queue.  The  operations  QF.ntcr  and  QRemove  respectively 
append  an  element  to  die  tail  of  a  FIFO  Queue  and  remove  one  from  it’s  head.  Assume  Q  to  be  empty 
initially. 

T  :  QEnter(Q ,  X) 

T2:  QEnter(Q,  Y) 

T3 :  QReinove(Q) 

From  this  abstract  schedule  and  the  initial  contents  of  the  Queue,  one  can  deduce  the  state  of  Q  at  any  point 
in  the  schedule.  Thus  one  may  conclude  that  the  QRemove  operation  returns  X,  and  that  only  Y  remains  on 
the  Queue  at  the  end  of  the  schedule. 

* 

3.2  Dependencies  and  Consistency 

By  examining  an  abstract  schedule,  it  is  possible  to  determine  what  dependencies  exist  among  the 
transactions  in  the  schedule.  The  notation  D:  T^X  — >0  TpY  will  be  used  to  represent  the  dependency  D 
formed  when  transaction  T  performs  operation  X  and  transaction  T.  subsequently  performs  operation  Y  on 
some  common  object  O.  The  object,  transaction,  or  dependency  identifiers  may  be  omitted  when  they  are 
unimportant.  The  set  of  ordered  pairs  {(T,  Tp}  for  which  there  exist  X,  Y  and  O  such  that  D:  T;:X  -+0  T^:Y 
forms  a  relation,  denoted  <D>  IfT  <D  T,  T  precedes  Tj  and  T.  depends  on  T,  under  the  dependency  D. 


*In  Section  4.4  we  will  define  a  second  kind  of  schedule,  the  invocation  xheaule,  which  reflects  the  concurrency  of  specific 
implemcntaUons. 
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Hxumplcs  of  dependencies  and  Uicir  corresponding  relations  can  be  drawn  from  traditional  database 
systems.  For  instance,  consider  a  system  in  which  no  semantic  knowledge,  cither  about  entire  transactions  or 
about  their  component  operations,  is  available  to  the  concurrency  control  mechanism.  The  only  requirement 
is  that  each  individual  transaction  be  correct  in  itself:  it  must  transform  a  consistent  initial  state  of  the 
database  to  a  consistent  final  state.  Under  these  conditions,  only  serializable  abstract  schedules  can  be 
guaranteed  to  preserve  the  correctness  of  individual  transactions. 

Since  all  operations  are  indistinguishable,  only  one  possible  dependency  D  can  be  defined:  T.  T,  if  Tj 
performs  any  operation  on  an  object  later  operated  on  by  l'2.  Now,  consider  <*u.  the  transitive  closure  of  <D. 
A  schedule  is  ordcrable  with  respect  to  {<D}  iff  <*D  is  a  partial  order.  In  other  words,  there  arc  no  cycles  of 
the  form  T,  T,  T  <.,  T,.  In  general,  a  schedule  is  ordcrable  with  respect  to  S,  where  S  is  a  set  of 

dependency  relations,  iff  each  of  the  relations  in  S  have  a  transitive  closure  that  is  a  partial  order.  The 
relations  in  S  arc  referred  to  as  proscribed  relations,  and  we  will  use  ordcrability  with  respect  to  a  set  of 
proscribed  dependency  relations  to  describe  ordering  properties  of  groups  of  transactions.  Abstract  schedules 
that  are  ordcrable  with  respect  to  a  specified  set  of  proscribed  relations  will  be  called  consistent  abstract 
schedules. 

It  can  be  shown  that  ordcrability  with  respect  to  {<D}  is  equivalent  to  scriali/.ability  [Eswaran  76].  Given  a 
schedule  ordcrable  with  respect  to  {<D}.  a  transaction  T.  and  the  set  O  of  objects  to  which  T  refers,  every 
other  transaction  that  refers  to  an  object  in  O  can  unambiguously  be  said  cither  to  precede  T  or  to  follow 
T.  Thus  T  depends  on  a  well-defined  set  of  transactions  that  precede  it,  and  a  well-defined  set  of  transactions 
depend  on  T.  Each  transaction  sees  the  consistent  database  state  lett  by  those  transactions  that  precede  it,  and 
(by  assumption)  leaves  a  consistent  state  for  those  that  follow.  The  set  of  schedules  for  which  <  D  is  a  partial 
order  constitutes  the  set  of  consistent  abstract  schedules  for  a  system  that  employs  no  semantic  knowledge. 

The  scheme  described  above  prevents  cycles  in  the  most  general  possible  dependency  relation,  hence  it 
maximally  restricts  concurrency.  Ity  considering  the  semantics  of  operations  on  objects,  it  is  possible  to 
identify  some  dependency  relations  for  which  cycles  may  be  allowed  to  form.  For  example,  consider  a 
database  with  a  Rcad/Writc  concurrency  control.  Such  systems  recognize  two  types  of  operations  on  objects: 
Read(R)  and  Write(W).  Thus  there  arc  4  possible  dependencies  between  a  pair  of  transactions  that  access  a 
common  object: 

•  T:R-*CT.:R.  T  reads  an  object  subsequently  read  by  T^. 

•  D2:  TaR  ~*Q  T:W.  T  reads  an  object  subsequently  modified  by  Tj. 

•  D3:  T:W  — »qT.:R.  T  modifies  an  object  subsequently  read  by  T.. 
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•  1)4:  T:W  — T:W.  I',  modifies  an  object  subsequently  modified  by  1'.. 

The  earlier  scheme,  by  not  distinguishing  between  these  dependencies,  prevents  cycles  from  forming  in  the 
dependency  relation  <|y  which  is  the  union  of  all  four  individual  relations,  by  contrast.  Read/ Write 
concurrency  controls  take  into  account  the  fact  that  R  -*  R  dependencies  cannot  influence  system  behavior. 
That  is.  given  a  pair  of  transactions.  1^  and  T,.  and  an  abstract  schedule  in  which  both  T  and  T,  perform  a 
Read  on  a  shared  object,  the  semantics  of  Read  operations  ensure  that  neither  T  T,  nor  any  other 
transaction  in  die  schedule  can  determine  whether  Tj  <D  T,  or  I  ,  <()  T(.  Since  these  dependencies  cannot 
be  observed,  they  cannot  compromise  scriali/ability.  nor  can  they  affect  the  outcome  of  transactions.  We  call 
dependencies  meeting  this  criterion  insignificant.  Korih  has  jIso  noted  that  when  operations  arc 
commutative,  dieir  ordering  does  not  affect  seriali/abiliry  [Korth  83]. 


For  die  Read/Writc  case,  the  necessary  condition  for  scriali/ability  can  be  restated  as  follows  in  terms  of 
dependency  relations:  a  schedule  is  serializable  if  it  is  orderable  with  respect  to  {<D  ifJ  „  }  [Gray  75],  By 
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allowing  multiple  readers.  Rcad/Writc  schemes  permit  the  formation  of  cycles  in  die  <n  dependency 

ut 

relation,  and  in  relations  that  include  <n  ,  while  preventing  cvclcs  ir,  the  relation  that  is  the  union  of  <„  .  <„ 

l  z  u3 

and  <D  .  For  example,  consider  the  following  schedules,  which  have  identical  effects  on  die  system  state: 


T 

T 

T 


1 

2 

1 


*(0J 

R(o;j 

W(01) 


T  •  R(0  ) 
T i :  R(0t) 
Tt:  W(01) 


In  the  first  schedule,  T,  <D  T2  and  T2  <D  Tj.  Hence,  there  is  a  cycle  in  the  relation  <u  uD  ,  although 
<u  is  cycle-free.  In  the  second  schedule,  the  first  two  steps  are  reversed  and  neither  cycle  is  present. 


On  the  other  hand,  the  following  two  schedules  arc  not  necessarily  identical  in  effect: 


T, 

t: 


R(0j) 

W(0t) 

W(0t) 


T2:  W(0a) 
V  R(0:) 
“  W(0i) 


1  ■ 


In  this  case,  the  first  schedule  is  not  serializable  because  T2  <D  T,  and  T2  <D  thus  forming  a  cycle  in  the 
relation  <D  ,  which  is  a  sub-relation  of  <D  .  T:  observes  02  before  it  is  written  by  T2,  but  the  final 

state  of  02  reflects  the  Write  of  rather  than  T2,  implying  that  T2  ran  after  T2>  The  second  schedule  has  no 
cycle  and  is  serializable. 


In  summary,  ordcrability  with  respect  to  a  set  of  proscribed  dependency  relations  provides  a  precise  way  to 
characterize  consistent  schedules.  For  a  concurrency  control  that  enforces  scriali/ability  with  no  semantic 
knowledge  at  all  about  operations,  the  set  of  proscribed  relations  must  contain  <D,  which  is  equivalent  to  the 
union  of  every  possible  dependency  relation.  For  a  Rcad/Writc  database  scheme,  the  set  contains  the 
'r_w  u  W-.R  u  w— w  rc'ab°n-  When  typc-spccific  semantics  arc  considered,  type-specific  dependency 
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relations  t  <>c  dc lined  lor  each  type.  In  Section  4,  dependencies  are  used  to  define  interleaving 
spec  feat  ions  for  various  abstract  types.  These  specifications  provide  the  information  needed  to  determine 
how  an  individual  type  can  contribute  toward  maintaining  a  global  ordering  property  such  as  seriaiizabilily. 
If  a  specification  guarantees  orderability  with  respect  to  die  union  of  all  significant  dependency  relations  for  a 
given  type,  then  it  is  strong  enough  to  permit  scriali/ability.  In  general,  however,  more  concurrency  can  be 
obtained  when  only  weaker  ordering  properties  are  guaranteed.  The  way  in  which  the  interleaving 
specifications  of  multiple  types  interact  to  preserve  global  ordering  properties  is  discussed  in  Section  5. 

3.3  Dependencies  and  Cascading  Aborts 

Dependencies  are  also  useful  in  understanding  cascading  aborts.  A  cascading  abort  is  possible  when  a 
dependency  forms  between  two  transactions,  the  first  of  which  is  uncommitted.  An  abort  by  this 
uncommitted  transaction  may  cascade  to  those  that  depend  on  it.  Whether  or  not  a  cascade  actually  must 
occur  depends  on  the  exact  type  of  dependency  involved,  and  the  properties  of  the  object  being  acted  upon. 
For  example,  consider  the  four  general  dependency  relations  that  arise  in  Read/Write  database  systems. 
R  —  R  dependencies  are  insignificant,  and  can  never  cause  cascading  aborts.  This  is  analogous  to  the  role  of 
these  dependencies  in  determining  orderability.  Likewise.  R  — >  W  and  W  — ♦  W  dependencies  need  not  cause 
cascading  aborts,  because  in  both  cases  the  outcome  of  the  second  transaction  docs  not  depend  on  data 
modified  by  the  first"  Cy  contrast.  \V  — *  R  dependencies  represent  a  transfer  of  information  between  the  two 
transactions.  !r.  the  absence  of  any  additional  semantic  information,  it  must  be  assumed  that  an  abort  of  the 
first  transaction  will  affect  the  outcome  of  the  second,  which  must  therefore  also  be  aborted. 

Once  the  dependencies  that  could  lead  to  cascading  aborts  have  been  identified,  their  formation  must  be 
controlled.  Stated  in  terms  of  abstract  schedules:  starting  from  the  first  of  the  two  operations  that  form  the 
dependency  there  must  be  no  overlapping  of  the  two  transactions  in  the  schedule,  widi  die  prior  transaction 
in  the  dependency  relation  completing  first.  Such  schedules  will  be  called  cascade-free.  Note  that  some 
consistent  schedules  may  not  be  cascade-free,  and  vice-versa. 

4  Specification  of  Shared  Abstract  Types 

This  section  focuses  on  the  typed  operations  that  make  up  transactions  and  discusses  how  to  specify  their 
local  synchronization  properties.  The  traditional  specification  of  an  abstract  type  describes  the  behavior  of 
the  type's  operations  in  terms  of  preconditions,  postconditions,  and  an  invariant.  This  specification  must  be 
augmented  in  several  ways  to  complete  the  description  of  a  shared  abstract  type  in  our  model.  In  the  first 
place,  the  undo  operation  corresponding  to  each  regular  operation  must  be  specified  in  terms  of 
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It  ray  be  necessary  to  control  the  formation  of  these  dependencies  anyway,  if  an  insufficiently  flexible  recovery  strategy  is  used. 
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pa-conditions,  postconditions  and  tiic  invariant.  Specification  of  the  undo  operations  themselves  is  not 
considered  further  in  this  paper.  It  is  important  to  note,  however,  that  the  set  of  consistent  abstract  schedules 
defined  by  tnc  interleaving  specification  for  a  type  also  implicitly  includes  schedules  in  which  undo 
operations  are  inserted  at  all  possible  points  after  an  operation  has  been  performed  but  prior  to  the  end  of  the 
invoking  transaction.  This  reflects  the  assumption  that  it  must  be  possible  to  undo  any  operation  prior  to 
transaction  commitment.  As  will  be  shown  in  Section  4.3.  this  is  especially  important  for  types  that  do  not 
attempt  to  enforce  scriali/ability  of  transactions. 

The  specification  of  a  shared  abstract  type  must  also  include  a  description  of  how  operations  on  behalf  of 
multiple  transactions  can  be  interleaved.  This  interleaving  specification  can  be  used  by  application 
programmers  to  describe  their  needs  to  prospective  type  implementors  or  to  evaluate  die  suitability  of  existing 
types  for  their  applications.  The  specification  of  a  shared  abstract  type  must  also  list  those  dependencies  that 
will  be  controlled  to  prevent  cascading  aborts.  This  part  of  the  specification  is  used  mainly  by  the  type's 
implementor. 

When  specifying  how  operations  on  a  shared  object  may  interact,  the  amount  of  concurrency  that  can  be 
permitted  depends  in  part  on  how  much  detailed  knowledge  is  available  concerning  the  semantics  of  the 
operations  [Kung  79].  We  have  shown  how  concurrency  controls  that  distinguish  those  operations  that  only 
observe  the  state  of  an  object  ("Reads")  from  those  that  modiry  it  ("'Writes")  can  achieve  greater  concurrency 
than  protocols  not  making  this  distinction.  To  increase  concurrency  further  while  still  providing 
scriali/ability.  one  can  take  advantage  of  moi?  semantic  knowledge  about  the  operations  being 
performed  [Korth  83].  Section  4.1  illustrates  how  this  is  done  in  specifying  Directories,  using  the  concepts 
and  notation  of  the  last  section. 

When  enough  concurrency  cannot  be  obtained  even  after  fully  exploiting  die  semantics  of  the  operations  on 
a  type,  it  is  necessary  to  dispense  with  scrializability  and  substitute  orderability  with  respect  to  some  weaker 
set  of  proscribed  dependency  relations.  Sections  4.2  and  4.3  illustrate  this  by  comparing  a  serializable  Queue 
type  with  a  variation  that  preserves  a  weaker  ordering  property. 

Finally,  Section  4.4  discusses  how  implementations  may  reorder  operations  to  obtain  even  more 
concurrency,  and  the  steps  that  type  implementors  must  take  to  demonstrate  die  correctness  of  an 
implementation. 
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4.1  Directories 

As  a  first  trample,  consider  a  Directory  data  type  that  is  intended  to  provide  a  mapping  between  text  strings 
and  capabilities  for  arbitrary  objects.  Ihe  trual  operations  are  provided: 

•  l)irlnsert(dir,  str,  capa):  inserts  capa  into  Directory  dir  with  key  string  str.  Returns  ok  or  duplicate 
key.  The  undo  operation  for  Diruiscrt  removes  the  inserted  entry,  if  the  insertion  was  successful. 

•  l)irl)cletc(dir,str):  deletes  the  capability  stored  with  key  string  str  from  dir.  Returns  ok  or  not 
found.  The  undo  operation  for  DirDelcte  restores  the  deleted  capability,  if  the  deletion  was 
successful. 

•  Dirl.ookup(dir,  str):  searches  for  a  capability  in  dir  with  key  string  str.  Returns  the  capability  capa 
or  not  found.  The  undo  operation  is  null,  because  Dirl.ookim  docs  not  modify  the  Directory. 

•  DirDump(dir):  returns  a  vector  of  <str,capa>  pairs  with  the  complete  contents  of  the  Directory  dir. 

The  undo  operation  for  DirDump  is  null. 

Suppose  one  wishes  to  specify  the  Directory  type  so  as  to  permit  serialization  of  transactions  that  include 
operations  on  Directories.  One  approach  would  be  to  model  each  Dirlnsert  or  DirDelcte  operation  as  a  Read 
operation  followed  by  a  Write  operation,  and  to  model  each  Dirl.ookup  ot  DirDump  operation  as  a  Read 
operation.  The  Directory  type  could  then  be  specified  using  the  Read/ Write  dependency  relations  discussed 
previously. 

The  difficulty  with  using  such  limited  semantic  information  is  that  concurrency  is  restricted  unnecessarily. 
For  example,  suppose  Directories  have  been  implemented  using  a  standard  two-phase  Read/Write  locking 
mechanism.  Consider  the  operation  DirLookup(dir,  "Foo"),  which  will  be  blocked  trying  to  obtain  a  Read 
lock  if  another  transaction  has  performed  Dirl)eletc(dir,  "Fum")  and  holds  a  Write  lock  on  the  Directory 
object.  The  outcome  of  DirLookup(dir,  "Foo")  does  not  depend  in  any  way  on  the  eventual  outcome  of 
DirDeletc(dir,  "Fum”)  (which  may  later  be  aborted),  or  vice-versa,  so  this  blocking  is  unnecessary.  Because 
Dirl)clctc(dir,  "Fum")  may  be  part  of  an  arbitrarily  long  transaction,  the  Write  lock  may  be  held  for  a  long 
time  and  severely  degrade  performance. 

The  unnecessary  loss  of  concurrency  in  this  example  is  not  the  fault  of  this  particular  implementation.  It  is 
caused  by  the  lack  of  semantic  information  in  the  Directory  specification.  By  using  more  knowledge  about 
the  operations,  this  problem  can  be  alleviated.  Instead  of  expressing  the  interleaving  specification  for  this 
type  in  terms  of  Read  and  Write  operations,  the  type-specific  Directory  operations  can  be  employed  to  define 
dependencies  and  the  interleaving  specifications  can  be  expressed  in  terms  of  these  type-specific 
dependencies. 

To  keep  the  number  of  dependencies  to  a  minimum,  the  operations  for  the  Directory  data  type  will  be 
divided  into  three  groups: 
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•  Those  that  modify  a  particular  entry  in  the  Directory.  Dirluscrt  and  DirDelctc  operations  tliat 
succeed  are  in  this  class.  These  are  Modify  (M)  operations. 

•  Those  that  observe  the  presence,  absence,  or  contents  of  a  particular  entry  in  the  Directory. 
Diri.ookup  is  in  this  class,  as  arc  Dirluscrt  and  DirDelctc  operations  that  fail.  These  are  Lookup 
(I.)  operations. 

•  Those  that  observe  properties  of  the  Directory  that  cannot  be  isolated  to  an  individual  entry. 
DirDuitip  is  the  only  operation  in  this  class  that  we  have  defined:  an  operation  that  returned  the 
number  of  entries  in  the  Directory  would  also  be  in  this  class.  These  arc  Dump  (D)  operations. 

Note  that  in  some  cases  operations  that  fail  are  distinguished  from  those  tliat  succeed.  In  addition  to  the 
operations  and  their  outcomes,  the  dependencies  also  take  into  account  data  supplied  to  the  operations  as 
arguments  or  otherwise  specific  to  the  particular  object  acted  upon.  In  the  following  list  of  dcpcndcneics,  the 
symbols  a  and  a'  represent  distinct  key  string  arguments  to  Directory  operations. 


The  complete  set  of  dependencies  for  this  type  is: 

•  Dj:  TtMfd)  — *  T.:M(ct’).  T.  modifies  an  entry  with  key  string  cr,  and  T.  subsequently  modifies  an 
entry  with  a  different  key  string,  o’. 

•  D2:  T.:M(<t)  — ♦  T:M(<j).  T  modifies  an  entry  with  key  string  o,  and  T.  subsequently  modifies 
the  same  entry. 

•  D^:  T:M(a)  —*  T  :L(a’)-  T;  modifies  an  entry  with  key  string  a,  and  T  subsequently  observes  an 
entry  with  a  different  key  siring,  o’. 

•  D4:  T.:M(a)  — ►  T.:L(a).  T  modifies  an  entry  with  key  string  a.  and  T  subsequently  observes  the 

same  entry.  J 

•  D5:  T^Lfu)  — »  T.;L((j’)-  observes  an  entry  with  key  string  <r,  and  Tj  subsequently  observes  an 
entry  with  a  different  key  string  <r'. 

•  D6:  Tc.Lfcr)  — +  T:L(a).  T  observes  an  entry  with  key  string  a,  and  T.  subsequently  observes  the 
same  entry. 

•  D?:  TaLfa)  — ♦  T:M(ct’).  T;  observes  an  entry  with  key  string  a,  and  T  subsequently  modifies  an 
entry  with  a  different  key  string  o’. 

•  D„:  T.:L(cr)  — ►  T.:M(cr).  T.  observes  an  entry  with  key  string  a,  and  T.  subsequently  modifies  the 

0  1  J  1  J 

same  entry. 

•  D5:  TeD  — »  T^:M(a).  T  dumps  the  entire  contents  of  the  Directory,  and  Tj  subsequently 
modifies  an  entry  with  key  string  o. 

•  D1Q:  r,:D  -+  T.:L(cr).  T(  dumps  the  entire  contents  of  the  Directory,  and  T.  subsequently 
observes  an  entry  with  key  string  o. 
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•  Dj,:  T:\Ucj)  — ♦  T:D.  T  modifies  an  entry  with  key  string  a,  and  T.  subsequently  dumps  the 
entire  contents  of  the  Directory. 

•  Dp:  T:I.(cr)  — *  I  ’D.  T.  observes  an  entry  with  key  string  a,  and  T  subsequently  dumps  the 
entire  contents  of  tnc  Directory. 

•  D.  '  1  :D  —*  T  :D.  T  dumps  the  entire  contents  of  the  Directory  and  T  subsequently  dumps  the 
Directory  as  well. 


This  list  is  long,  but  it  is  actually  quite  simple  to  derive.  There  is  a  family  of  dependencies  for  each  pair  of 
operation  classes.  The  key  to  defining  the  specific  dependencies  is  the  observation  that  when  two  operations 
refer  to  different  strings,  the  relationship  between  the  transactions  that  invoked  them  is  not  die  same  as  when 
they  refer  to  identical  strings.  Those  families  of  dependencies  for  which  both  operation  classes  take  a  string 
argument  therefore  have  two  members,  corresponding  to  these  two  eases.  The  families  for  which  one  of  the 
operation  classes  is  Dump  have  only  a  single  member.  In  general,  insight  into  the  scmandcs  of  a  type  is 
needed  to  define  the  set  of  possible  dependencies. 


Like  the  R  — *  R  dependency,  many  of  the  Directory  dependencies  arc  insignificant  and  cannot  affect  the 
outcome  of  transactions.  Hence,  they  may  be  excluded  from  the  set  of  proscribed  dependencies  for  this  type. 
The  dependencies  dial  may  be  disregarded  arc: 

•  Those  for  which  neither  operation  in  the  dependency  modifies  the  Directory  object:  D6,  D10,  D12 
and  D13.  These  arc  directly  analogous  to  die  R  — *  R  dependency. 


•  Those  for  which  the  two  operations  in  die  dependency  refer  to  different  key  strings:  Dr  D3>  D5> 
and  Dr 


In  terms  of  the  remaining  dependencies,  tine  interleaving  specification  for  Directories  states  that  an  abstract 


schedule  involving  Directories  is  consistent  if  it  is  orderable  with  respect  to  {< 


}.  The 


D2cD4uD8uD9uD11 

abstract  Directory  thus  defined  behaves  like  a  collection  of  associatively-addressed  elements,  with 
scrializability  prcscrvable  independently  for  each  element.  Transactions  containing  operations  that  apply  to 
the  entire  Directory,  such  as  DirDump,  may  also  be  serialized,  as  may  diose  that  refer  to  multiple  elements  or 
elements  that  are  not  present. 


Only  two  of  die  Directory  dependencies  have  the  potential  to  cause  cascading  aborts.  These  arc  D4  and 
Du.  In  both  cases,  the  first  operation  in  the  dependency  modifies  an  entry  and  the  second  operation  observes 
that  modification. 
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4.2  FIFO  Queues 

Similar  specifications  can  be  developed  for  other  data  types.  The  FIFO  Queue  provides  an  interesting 
example.  We  will  only  consider  two  operations: 

•  QFnter(qucue.  capa):  Adds  an  entry  containing  the  pointer  capa  to  the  end  of  queue.  The  undo 
operation  for  QEntcr  removes  this  entry. 

•  QRemove(queuc):  Removes  die  entry  at  the  head  of  queue  and  returns  the  pointer  capa  contained 
therein.  If  queue  is  empty,  the  operation  is  blocked,  and  waits  until  queue  becomes  non-empty. 

The  undo  operation  for  QReinove  restores  the  entry  to  the  head  of  queue. 


In  order  to  permit  serialization  of  transactions  that  contain  operations  on  strict  FIFO  Queues,  and  to 
prevent  cascading  aborts,  numerous  properties  must  be  guaranteed.  For  instance: 

•  If  a  transaction  adds  several  entries  to  a  Queue,  these  entries  must  appear  together  and  in  the  same 
order  at  die  head  of  the  Queue. 

•  Any  entries  added  to  a  Queue  by  a  transaction  may  not  be  observed  by  another  transaction  unless 
the  first  transaction  terminates  successfully. 

•  If  two  transactions  each  make  entries  in  two  Queues,  the  relative  ordering  of  the  entries  made  by 
the  two  transactions  must  be  the  same  in  both  Queues. 

It  is  very  easy  to  destroy  these  properties  if  unrestricted  interleaving  of  operations  is  allowed.  For  instance, 
if  QEntcr  operations  from  different  transactions  are  interleaved,  the  entries  made  by  each  transaction  will  not 
appear  in  a  block  at  the  head  of  the  Queue. 


In  defining  the  dependencies  for  the  Queue  type,  it  is  necessary,  as  it  was  in  the  ease  of  Directories,  to 
distinguish  individual  elements  in  the  Queue.  It  is  assumed  that  each  element  is  assigned  a  unique  identifier3 
when  it  is  entered  on  the  Queue.  The  symbols  a  and  a'  are  used  to  represent  the  distinct  identifiers  of 
different  elements,  and  the  QEntcr  and  QRemove  operations  are  abbreviated  as  E  and  R  respectively.  The 
complete  set  of  dependencies  for  Queues  is: 

•  T:E(tr)  —*q  T.:F.(a’).  T  enters  an  element  cr’  into  the  queue  Q  after  T;  has  previously 
entered  an  element  a. 

•  D2:  T.:E(ct)  — »q  T^RCct’).  T.  removes  element  <7’  after  T  entered  element  a. 

•  D3:  Tj:E(<7)  — >q  T.:R(<r).  T.  removes  the  element  a  that  was  entered  by  Tj. 

•  D4:  T.:R(ct)  — >q  TjiECo’).  T  enters  element  <j’  after  T  removed  element  a. 


^Ihe  identifier  need  not  be  giobaliy  unique,  just  unique  among  those  generated  for  the  particular  Queue  object 
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•  D5:  r:R(o)  — *g  1  .:R(o").  I',  removes  element  o’  after  T  removed  element  o. 

In  a  Rcad/Writc  synchronization  scheme,  QFnter  must  be  modeled  as  a  Write  operation,  and  QReinovc 
must  be  modeled  as  a  Read  followed  by  a  Write.  Recall  that  such  a  scheme  must  prevent  cycles  in  the 
<r_w  u  w— R  w— w  dependency  relation.  In  this  ease,  preventing  cycles  in  this  general  dependency 
relation  is  unnecessarily  restrictive.  Consider  dependency  F>2.  which  is  formed  when  a  transaction  removes  a 
Queue  element  alter  another  transaction  has  previously  entered  a  different  Queue  element.  Neither  of  the 
transactions  performing  the  operations  can  detect  their  ordering,  nor  can  a  third  transaction.  The  same 
applies  to  dependency  D4,  which  is  die  inverse  of  D2.  As  was  die  ease  for  Directories,  concurrency  can  be 
increased  by  disregarding  insignificant  dependencies. 


To  provide  a  strictly  FIFO  Queue,  one  must  guarantee  that  abstract  schedules  are  ordcrable  v/ith  respect  to 
the  compound  <D  lD  (j  d  relation,  but  cycles  may  be  permitted  to  form  in  relations  diat  include  D2  or  D4  as 
long  as  this  property  is  not  violated.  For  example,  consider  the  following  schedule,  in  which  two  transactions 
operate  on  a  Queue  that  initially  contains  {A,  B}: 


l  • 


QEnter(Q ,X) 


T2:  QRemove(Q)  returns  A 
Tt:  QEnter(Q.Y) 

At  step  2  of  diis  schedule  a  D2  dependency  is  formed,  hence  T{  <D  T2>  At  step  3,  however,  a  D4  dependency 

is  formed  with  T,  <D  Tj.  Clearly  a  cycle  exists  in  the  compound  relation  <D  uD  .  It  is  easy  tc  create  other 
4  2  4 

examples  of  consistent  abstract  schedules  that  demonstrate  a  cycle  in  the  basic  <n  (or  <n  )  relation,  or  in  a 

u2  u4 

compound  relation  formed  from  D2  (or  D4)  together  with  Dr  D3  and  D5. 


The  dependency  relations  can  also  be  used  to  characterize  schedules  susceptible  to  cascading  abort. 

Dependency  relation  <n  is  similar  to  the  W  — *  W  dependency.  Since  entries  made  by  an  aborted  transaction 
J1 

can  be  transparently  removed  from  the  Queue,  there  is  no  danger  of  cascading  abort.  Relations  <n  and  <n 

3  5 

arc  more  similar  to  W  — *  R  dependencies.  In  a  D3  dependency,  information  is  transferred  between  the 
transactions  in  the  form  of  the  queue  element  a;  this  dependency  clearly  can  cause  cascading  aborts.  A  D$ 
dependency  can  also  cause  cascading  aborts,  because  the  removal  of  an  element  by  the  first  transaction  affects 
which  element  is  received  by  the  second  transaction. 


While  this  definition  of  consistency  for  Queues  is  an  improvement  over  a  Read/Write  scheme,  it  is  still  very 
restrictive  of  concurrency.  It  allows  at  most  two  transactions,  one  performing  QEnter  operations  and  one 
performing  QRemovc  operations,  to  access  a  Queue  concurrently.  Unlike  the  Directory,  the  Queue  is 
intended  to  preserve  a  particular  ordering  of  the  elements  contained  in  it.  A  system  based  on  serializable 
transactions  guarantees  that  transactions  can  be  placed  in  some  order;  by  enforcing  a  particular  order,  data 
types  such  as  queues  (and  stacks)  restrict  concurrency. 
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4.3  Queues  Allowing  Greater  Concurrency 

The  preceding  examples  show  how  the  use  of  semantic  knowledge  about  operations  on  a  shared  abstract 
type  permits  increased  concurrency.  Once  such  knowledge  is  incorporated,  the  limiting  factor  in  permitting 
concurrency  becomes  knowledge  about  the  consistency  constraints  that  the  operations  in  a  transaction 
attempt  to  maintain  [Kung  79],  This  knowledge  concerns  the  semantics  of  groups  of  operations  rather  than 
individual  ones.  For  example,  a  consistency  constraint  might  state  that  every  Queue  entry  of  type  A  is 
immediately  followed  by  one  of  type  IF  The  potential  for  such  constraints  was  the  cause  of  the  concurrency 
limitations  observed  above. 


If  it  is  possible  to  restrict  the  consistency  constraints  that  a  programmer  is  free  to  require,  types 
guaranteeing  ordering  properties  weaker  than  scriali/ability  may  be  acceptable.  This  may  permit  further 
increases  in  concurrency.  A  variation  of  the  queue  type  can  be  used  to  demonstrate  this. 


One  of  die  most  common  uses  for  a  queue  is  to  provide  a  buffer  between  activities  that  produce  and 
consume  work.  F'rcqucntly,  the  exact  ordering  of  entries  on  the  queue  is  not  important.  What  is  crucial  is 
that  entries  put  on  the  rear  of  the  queue  do  not  languish  in  the  queue  forever;  they  should  reach  the  head  of 
the  queue  "fairly"  with  respect  to  other  entries  made  at  about  the  same  time.  A  data  type  having  this 
non-starvation  property  can  be  defined:  the  Weakly-FIFO  Queue  (WQueue  for  short).  A  similar  type,  the 
Semi-Queue ,  has  been  defined  by  Weihl  [Weihl  83b]. 


The  operations  on  WQueucs  and  their  corresponding  undo  operations  are  similar  to  those  for  Queues,  but 

the  interleaving  specification  for  WQueucs  allows  more  concurrency.  The  dependencies  for  the  WQueue 

type  are  the  same  as  for  the  strict  Queue.  However,  where  the  strict  Queue  required  that  consistent  abstract 

schedules  be  ordcrable  with  respect  to  {<D  uD  uD  },  the  WQueue  permits  cycles  to  occur  in  all  the 

dependency  relations  save  one:  <n  .  By  allowing  cycles  in  <n  ,  the  interleaving  of  entries  by  multiple 

u3  U1 

transactions  becomes  possible.  Similarly,  removing  D5  from  the  set  of  proscribed  dependency  relations 
permits  WQRcmove  operations  to  be  interleaved. 


To  take  full  advantage  of  the  greater  concurrency  allowed  by  this  interleaving  specification,  the  semantics  of 
WQRcmove  differ  slightly  from  those  of  QRemove.  If  the  transaction  that  inserted  the  headmost  entry  in  the 
queue  has  not  committed,  that  entry  cannot  be  removed  without  risking  the  possibility  of  a  cascading  abort. 
Instead,  WQRcmove  scans  the  WQueue  and  removes  the  headmost  entry  for  which  the  inserting  transaction 
has  committed.  If  no  such  element  can  be  found,  any  elements  inserted  by  the  transaction  doing  the 
WQRcmove  become  eligible  for  removal.  If  neither  a  committed  entry  nor  one  inserted  by  the  same 
transaction  is  available,  the  operation  is  blocked  until  an  inserting  transaction  commits. 
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Modifying  die  semantics  of  WQRcniovc  in  tliis  way  does  not  destroy  the  fairness  properties  of  the  WQucuc. 
No  entry  will  remain  in  die  WQucuc  forever  if: 

1.  The  transaction  that  entered  it  commits  in  a  finite  amount  of  time. 

2.  Transactions  that  remove  it  terminate  after  a  finite  amount  of  time. 

3.  Only  a  finite  number  of  transactions  remove  the  entry  and  then  abort. 

flic  behavior  of  the  WQucuc  is  best  illustrated  by  example.  In  what  follows,  a  WQucuc  is  represented  by  a 
sequence  of  letters,  with  die  left  end  of  the  sequence  being  die  head  of  the  WQucuc.  Lower  ease  italic  letters 
(a)  arc  used  to  denote  entries  for  which  the  WQLnter  operation  has  not  committed  (i.c.  the  transaction  that 
performed  WQF.nter  is  incomplete).  Upper  ease  bold  letters  (A)  arc  used  to  represent  entries  diat  have  not 
been  removed  and  for  which  the  entering  transaction  has  committed.  Upper  ease  italic  letters  arc  used  for 
entries  that  have  been  removed  by  an  uncommitted  WQRcmovc.  Superscripts  on  entries  affected  by 
uncommitted  operations  identify  the  transaction  that  performed  die  operation. 

Assume  that  the  WQueue  is  initially  empty.  If  transactions  Tx  and  T2  perform  WQEntcr(\VQ,  a)  and 
V\'QF.ntcr(WQ.  b)  respectively,  the  WQueue’s  state  becomes: 

{a1,  b2} 

Since  cycles  in  <Q  are  permitted,  Tt  may  also  add  another  entry,  yielding: 

{a’.b2,  c1} 

If  Tj_  and  T2  both  commit,  the  state  becomes: 

{A,  B,  C} 

Note  that  the  scrializability  of  Tj  and  T2  has  not  been  preserved.  Now  suppose  that  Tj  performs  WQRcmove 
and  another  transaction,  T4,  removes  two  more  elements: 

{A3,  B1,  C4} 

IfT3  now  aborts  andT4  commits,  the  final  state  becomes: 

{A} 

In  this  ease,  A  and  C  have  effectively  been  reversed,  even  though  they  were  inserted  initially  by  the  same 
transaction!  This  example  illustrates  an  important  difference  between  shared  abstract  types  diat  attempt  to 
preserve  scrializability  and  diosc  that  do  not:  when  a  type  permits  non-serial  execution  of  transactions, 
invoking  an  operation  and  subsequently  aborting  it  is  not  necessarily  equivalent  to  not  invoking  the  operation 
at  all.  While  we  do  not  explicitly  consider  the  undo  operations  in  defining  dependencies  or  interleaving 
specifications,  the  underlying  assumption  that  aborts  can  occur  at  any  time  prior  to  commit  implies  diat  undo 
operations  can  be  inserted  at  any  point  in  a  schedule  between  the  invocation  of  an  operation  and  the  dme  at 
which  the  invoking  transaction  commits. 
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Another  example  indicates  what  happens  when  an  uncommitted  entry  reaches  the  head  of  the  Queue. 
Suppose  the  initial  state  is: 

{a5.  *6} 

If T6  commits  butT5  remains  incomplete,  the  state  becomes: 

Ur5,  B} 

IfT-,  removes  an  element  at  this  time,  B  will  be  returned,  leaving: 

W} 

after  1 7  commits.  On  the  other  hand,  if  Ts  commits  after  T6,  but  before  the  remove  by  T7,  A  will  be  returned 
even  though  its  insertion  was  committed  after  B’s. 

To  summarize  the  comparison  between  the  WQueue  and  the  ordinary  Queue,  note  that  two  properties  of 

the  regular  Queue  have  been  sacrificed.  First  strict  FIFO  ordering  of  entries  is  not  guaranteed,  because 

aborting  WQReinove  operations  can  reorder  them.  Second,  transactions  that  operate  on  WQucucs  arc  not 

necessarily  serializable  with  respect  to  all  transactions  in  the  system.  Some  other  crucial  properties,  however, 

are  preserved.  The  WQueue  will  not  starve  any  entry,  and  it  enforces  an  ordering  of  those  transactions  that 

communicate  through  access  to  a  common  element  of  the  queue.  This  is  ensured  by  ordcrability  with  respect 

to  {<„  }.  These  modifications  greatly  increase  concurrency,  while  still  providing  a  data  type  that  is  useful  in 
u3 

many  situations. 

4.4  Proving  the  Correctness  of  Type  Implementations 

Whereas  the  user  of  a  type  may  employ  the  specified  properties  of  abstract  schedules  (along  with  the  rest  of 
the  type’s  specification)  to  reason  about  the  correctness  of  transactions,  the  implementor  of  a  type  must  prove 
the  correctness  of  an  implementation  given  the  order  in  which  operations  arc  actually  invoked.  Real 
implementations  may  reorder  the  operations  on  an  object  to  improve  concurrency  without  changing  the  type’s 
interleaving  specification.  Consider  an  implementation  of  the  Queue  type  in  which  elements  to  be  entered  by 
a  transaction  arc  first  collected  in  a  transaction-local  cache  and  entered  as  a  block  at  end-of-transaction.  This 
implementation  allows  any  number  of  transactions  to  invoke  the  QEnter  operation  simultaneously,  provided 
care  is  taken  to  serialize  correctly  transactions  involving  multiple  Queues.  By  actually  performing  the 
insertions  as  a  block,  this  implementation  effectively  reorders  the  individual  QEnter  operations  to  preserve 
consistency.  It  is  possible  to  reorder  QEnter  operations  in  this  way  because  QEnter  docs  not  return  any 
information  to  its  caller.  Formation  of  any  dependencies  that  might  result  from  its  invocation  can  therefore 
be  postponed.  The  ultimate  ordering  of  operations  in  the  abstract  schedule  is  determined  by  the 
implementation  once  all  the  QEnter  operations  to  be  performed  by  a  given  transaction  are  known.  Thus,  this 
implementation  has  the  benefit  of  more  knowledge  about  transactions  than  has  the  standard  implementation. 
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Invocation  schedules  lisl  operations  in  the  order  in  which  they  are  actually  invoked,  rather  than  in  order  of 
their  abstract  effects4.  For  example,  the  following  is  a  possible  invocation  schedule  for  a  Queue  implemented 

using  the  block-insertion  technique  described  above: 

T  :  QEnter(Q.Y) 

Tj :  QEnter(Q.X) 

T3:  QRemove(Q) 

If  T.  commits  before  T2>  the  implementation  reorders  the  two  QKnter  operations,  resulting  in  the  abstract 
schedule: 

T  :  QEnter ( Q ,  X) 

T2:  QEnt.er(Q,  Y) 

T3 :  QReinove(Q) 

The  mapping  between  invocation  schedules  and  abstract  schedules  is  many-one;  each  invocation  schedule 
implements  exactly  one  abstract  schedule,  but  an  abstract  schedule  may  be  implemented  by  multiple 
invocation  schedules.  The  synchronization  mechanism  used  by  an  implementation  determines  a  set  of 
invocation  schedules,  called  legal  schedules ,  that  are  permitted  by  the  implementation.  The  implementor 
must  snow-  that  ad  legal  invocation  schedules  map  to  consistent  abstract  schedules.  To  prevent  cascading 
aborts  as  well,  implementors  must  use  a  synchronization  strategy  that  restricts  the  set  of  legal  invocation 
schedules  tc  those  that  map  to  abstract  schedules  that  arc  in  the  intersection  of  the  consistent  and  cascade-free 
sets. 

5  Orderability  of  Groups  of  Transactions 

The  preceding  section  described  how  the  standard  specification  of  an  abstract  type,  which  only  seeks  to 
characterize  the  type’s  invariants  and  the  postconditions  for  its  operations,  can  be  augmented  with  an 
interleaving  specification  that  describes  the  local  synchronization  properties  of  objects.  In  this  section  we 
broaden  our  focus  from  the  properties  of  the  typed  objects  that  are  manipulated  by  transactions  to  the 
properties  of  entire  transactions.  We  first  examine  how  to  generalize  the  definition  of  consistent  abstract 
schedules  to  schedules  that  include  operations  on  more  than  one  object  type,  and  then  consider  how  ordering 
properties  of  groups  of  transactions  can  be  used  to  show  their  correctness. 


A 

It  is  assumed  that  the  actual  concurrent  execution  of  the  transactions  can  be  modeled  by  a  linear  ordering  of  their  component 
operations.  This  requires  that  the  primitive  operations  be  (abstractly)  atomic  In  the  multiprocessor  case,  all  linearizations  of  operations 
that  could  occur  simultaneously  yield  distinct  invocation  schedules. 


19 


5.1  How  the  Specifications  of  Multiple  Types  Interact 

Guaranteeing  ordcrability  with  respect  to  the  proscribed  relations  of  a  collection  of  individual  types  is  not 
sufficient  to  ensure  global  ordering  properties  of  transactions,  such  as  scrializability.  Consider  the  following 
schedule,  which  contains  transactions  that  operate  both  on  Queues  and  Directories.  Hach  of  these  types 
preserves  ordcrability  with  respect  to  the  union  of  all  significant  dependencies  for  the  individual  type,  in 
order  that  transactions  involving  the  type  may  potentially  be  serialized.  However,  this  propci ty  alone  does 

not  guarantee  scrializability  of  the  transactions.  For  example,  the  following  schedule  is  not  serializable: 

T  •  QEnter ( Q , X) 

QEnten( Q , Y) 

DirInsert(D,  "A",  Z) 

Di rDe 1 e  te( D  ,  "A") 

Let  <IV  stand  for  the  <„  ,,  „  relation,  defined  earlier  for  type  Directory.  Let  stand  for  the 

IV  D-,uD4^DgUDgUDj^  1  Q 

<„  .  n  _  relation,  defined  earlier  for  Queues.  Although  the  schedule  is  ordcrable  with  respect  to 
{<Djr,  <Q}.  it  is  not  serializable.  To  achieve  scrializability,  the  Queue  and  Directory  types  must  cooperate  to 
prevent  cycles  in  die  relation  {<Dirug}-  The  schedule  is  not  ordcrable  with  respect  to  diis  compound 
dependency. 


This  example  indicates  how  to  generalize  the  definition  of  consistency  to  apply  to  abstract  schedules 
containing  operations  on  multiple  types.  Assume  the  interleaving  specification  for  type  Y,  guarantees 
ordcrability  with  respect  to  {<D  },  the  interleaving  specification  for  type  Y2  guarantees  ordcrability  with 
respect  to  {<D  },  etc.  The  set  of  consistent  abstract  schedules  involving  types  Yr  Y,, ...  Yn  is  defined  as  those 
abstract  schedules  that  are  ordcrable  with  respect  to  {<D  uD  uD  )  1116  union  of  the  proscribed 
dependency  relations  of  the  individual  types.  A  set  of  types  whose  implementations  satisfy  this  property  is 
called  a  set  of  cooperative  types. 

The  need  for  cooperation  among  types  does  not  necessarily  imply  that  whenever  a  system  is  extended  by 
the  definition  of  a  new  type,  the  synchronization  requirements  of  all  existing  types  must  be  rethought.  When 
designing  a  system,  however,  the  implementors  of  cooperative  types  must  first  agree  on  a  synchronization 
mechanism  that  is  sufficiently  flexible  and  powerful  to  meet  all  of  their  requirements.  A  poor  choice  of 
mechanism  for  fundamental  building-block  types  will  have  an  adverse  effect  on  the  entire  system.  Section 
6  describes  a  mechanism  based  on  locking  that  permits  highly  concurrent  implementations  of  a  large  variety 
of  shared  abstract  types. 
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5.2  Correctness  of  T ransactions 

When  all  of  the  types  involved  in  a  group  of  transactions  cooperate  to  preserve  an  ordering  property 
equivalent  to  scrializability,  it  is  easy  to  show  that  die  correctness  of  transactions  is  not  affected  by 
concurrency.  Because  transactions  arc  completely  isolated  from  one  another,  a  transaction  can  be  proven 
correct  solely  on  the  basis  of  its  own  code  and  die  assumption  that  the  system  state  is  correct  when  die 
transaction  is  initiated. 

It  is  much  more  difficult  to  prove  the  correctness  of  transactions  when  they  include  operations  on  types  that 
permit  non-serializablc  interaction  among  transactions.  One  must  consider  die  possible  effects  of  interleaving 
each  transaction  with  any  other  transaction,  subject  to  the  constraints  of  whatever  ordering  property  is 
guaranteed  by  die  collection  of  types.  Ncvcrdiclcss,  in  many  practical  ^iiautions.  this  task  should  not  be 
insurmountable.  We  give  two  examples  of  situations  where  it  is  possible  to  make  useful  inferences  about  the 
behavior  of  transactions  even  though  they  preserve  an  ordering  property  weaker  than  scrializability. 

Users  often  invoke  the  DirDump  operation  on  a  Directory  when  they  arc  "just  looking  around."  In  such 
eases,  users  would  like  to  see  a  snapshot  of  the  Directory's  contents  at  an  instant  when  the  status  of  each  entry 
is  well  defined,  but  they  don’t  care  what  happens  to  the  Directory  thereafter.  If  all  Directory  operations 
attempt  to  enforce  scrializability.  using  DirDump  in  this  way  could  greatly  restrict  concurrency.  This  problem 
can  be  alleviated  by  modifying  the  specification  of  the  Directory  type  to  permit  limited  non-serializable 
behavior. 

Suppose  dependency  relations  containing  Dg:  T:D  — ►  T.:M(cr)  arc  removed  from  the  set  of  proscribed 
relations  for  the  modified  Directory  type.  That  is,  the  interleaving  specification  for  Directories  only  requires 
Durability  with  respect  to  «D  uD  D  D  }  instead  of  «D  uD  uD  uD  D  }•  Although  this  modified 
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Directory  allows  non-scrializ.able  behavior,  one  can  still  guarantee  that  certain  consistency  constraints  are  not 
violated.  For  example,  if  a  transaction  replaces  a  group  of  entries  in  a  Directory,  one  can  still  prove  that  no 
other  transaction  doing  DirLookup  operations  will  observe  an  incompatible  collection  of  entries. 

The  WQueue  of  section  4.3  provides  another  example  of  a  useful  type  that  permits  non-serializable 

interaction  of  transactions.  Although  the  ordering  property  for  WQueues  is  weaker  than  the  one  for  strict 

Queues,  some  interesting  properties  can  still  be  deduced  based  only  on  orderability  with  respect  to  {<n  }. 

u3 

Consider  two  transactions,  T1  and  T2,  and  two  WQueues,  Q1  and  Q2.  Suppose  T2  is  intended  to  move  all 
elements  from  Q2  to  Q2  and  T2  is  intended  to  move  all  elements  from  Q2  to  Qr  If  these  transactions  are  ran 
concurrently,  the  elements  should  all  wind  up  in  one  WQueue  or  the  other.  This  can  be  guaranteed  only  if 
<D  is  proscribed;  otherwise  elements  could  be  shuffled  endlessly  between  Q2  and  Q2  and  the  transactions 
might  never  terminate. 


6  A  Technique  for  Synchronizing  Shared  Abstract  Types 

We  have  developed  a  formalism  for  specifying  the  synchronization  of  operations  on  shared  abstract  types, 
and  interleaving  specifications  for  some  example  types  have  been  given.  This  section  outlines  a 
synchronization  mechanism  that  can  be  used  in  implementations  of  these  types.  While  we  do  not  describe  a 
particular  syntax  or  implementation  for  this  mechanism,  we  show  how  it  can  be  used  to  prevent  cascading 
aborts  and  control  the  interleaving  of  operations.  We  show  how  it  provides  the  cooperation  among  types  that 
is  needed  to  preserv  e  scriaii/ability  or  a  weaker  ordering  property  of  a  group  of  transactions.  Implementation 
sketches  for  die  shared  abstract  types  specified  in  Section  4  arc  given  as  examples  of  its  use. 

As  indicated  in  Section  4.4.  the  implementor  of  a  type  must  take  die  following  steps  to  demonstrate  the 
correctness  of  an  implementation: 

1.  characterize  the  set  of  legal  invocation  schedules,  that  is.  diosc  invocation  schedules  allowed  by 
die  synchronization  mechanism  used  in  die  implementation. 

2.  give  a  mapping  from  invocation  schedules  to  abstract  schedules,  and  prove  that  the 
implementation  carries  out  this  mapping. 

3.  prove  that  every  legal  invocation  schedule  yields  a  consistent  abstract  schedule  under  this 
mapping. 

This  three-part  task  is  simplest  for  implementations  diat  arc  idealized  in  that  they  do  not  reorder  operations 
on  objects.  Under  diese  conditions,  invocation  schedules  and  abstract  schedules  arc  equivalent,  and  the 
second  step  in  diis  process  can  be  eliminated.  The  examples  in  this  section  discuss  such  idealized 
implementations  of  types. 

6.1  Type-Specific  Locking 

The  proposed  synchronization  technique  is  based  on  locking ,  which  is  used  in  many  database  systems  to 
synchronize  access  to  database  objects.  There  are  many  variations  on  locking,  but  the  same  basic  principle 
underlies  them  all:  before  a  transaction  is  permitted  to  manipulate  an  object,  it  must  obtain  a  lock  on  the 
object  that  will  restrict  further  access  to  the  object  by  other  transactions  until  the  transaction  holding  the  lock 
releases  it. 

Locking  restricts  the  formation  of  dependencies  between  transactions  by  restricting  the  set  of  legal 
invocation  schedules.  Whenever  one  transaction  is  forced  to  wait  for  a  lock  held  by  another,  the  formation  of 
a  dependency  between  the  two  transactions  is  delayed  until  the  first  transaction  releases  the  lock.  Under  the 
well-known  two-phase  locking  protocol  [Eswaran  76],  no  transaction  releases  a  lock  until  it  has  already  claimed 
all  the  locks  it  will  ever  claim.  This  has  the  effect  of  converting  potential  cycles  in  dependency  relations  into 
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deadlocks  instead.  These  can  be  detected,  and  because  no  dependencies  have  yet  been  allowed  to  form,  cither 
transaction  can  be  aborted  without  affecting  the  other. 

Locking  is  a  conservative  policy,  because  it  delays  the  formation  of  any  dependency  that  is  part  of  a 
proscribed  relation,  not  just  those  dial  eventually  lead  to  cycles.  This  is  not  as  significant  a  disadvantage  as  it 
might  appear,  however,  because  formation  of  those  dependencies  that  transfer  information  (sec  Section  3.3) 
must  be  delayed  anyway  to  prevent  cascading  aborts.  In  fact,  the  even  more  restrictive  strategy  of  holding 
certain  locks  until  cnd-of-transaction  must  often  be  employed  to  ensure  dial  schedules  are  cascade-free. 
Furthermore,  it  is  the  conserv  ative  nature  of  locking  protocols  that  makes  them  a  suitable  mechanism  for  sets 
of  cooperative  types.  By  preventing  the  formation  of  any  dependencies  local  to  a  single  object,  cycles  in 
proscribed  relations  that  involve  multiple  types  arc  automatically  avoided  without  explicit  communication 
between  type  managers.  1'his  is  an  important  advantage,  because  it  allows  type  managers  to  be  constructed 
independently,  as  long  as  they  correctly  prevent  the  local  formation  of  dependencies. 

The  chief  disadvantage  of  many  locking  mechanisms  is  drat  they  sacrifice  concurrency  by  making  minimal 
use  of  semantic  knowledge  about  the  objects  being  manipulated.  The  simplest  locking  schemes  use  only  one 
type  of  lock,  and  hence  cannot  distinguish  between  significant  and  insignificant  dependencies.  Rcad/Writc 
locking  schemes  use  some  semantic  information,  but  are  not  flexible  enough  to  take  advantage  of  the  extra 
concurrency  specifiable  in  terms  of  typc-spccific  dependencies.  It  has  been  shown  [Rung  79]  that  tw-o-phase 
locking  is  optimal  under  such  conditions  of  limited  semantic  knowledge,  but  much  more  concurrency  can  be 
obtained  if  more  semantic  information  is  used.  The  locking  technique  described  here  generalizes  the  ideas 
behind  Rcad/Write  locking.  It  permits  the  definition  of  type-specific  locking  rules  that  reflect  the 
interleaving  specifications  of  individual  data  types.  More  restrictive  typc-sporjfic  locking  schemes  have 
previously  been  investigated  by  Korth  [Korth  83]. 

Two  observations  can  be  made  concerning  type-specific  dependencies.  First,  they  specify  the  way  in  which 
type-specific  operations  on  behalf  of  different  transactions  may  be  interleaved.  Analogously,  the  generalized 
locking  scheme  requires  the  definition  of  typc-spccific  lock  classes ,  which  correspond  roughly  to  the 
operations  on  the  type.  Second,  in  addition  to  the  operations,  the  dependencies  reflect  data  supplied  to  the 
operations  as  arguments  or  data  that  is  otherwise  specific  to  the  particular  object  acted  upon.  Therefore,  an 
instance  of  a  lock  in  the  generalized  locking  scheme  consists  of  two  parts:  the  type-spccific  lock  class  and 
some  amount  of  instance-specific  data.  It  is  the  inclusion  of  data  in  the  lock  instance  that  differentiates  our 
technique  from  Korth’s.  We  use  the  notation  {LockClass(iJula)}  to  represent  an  instance  of  a  lock. 

Once  the  lock  classes  for  a  type  have  been  defined,  a  Boolean  function  must  be  given  that  specifies  whether 
a  particular  new  lock  request  may  be  granted  as  a  function  of  those  locks  already  held  on  the  object.  In 
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accordance  widi  the  practice  in  database  literature,  ibis  function  will  be  represented  by  a  luck  compatibility 
hibU.  Only  those  locks  held  by  other  transactions  need  be  checked  for  compatibility;  a  new  lock  request  is 
always  compatible  w  it h  other  locks  held  by  tire  same  transaction. 

To  complete  the  description  of  a  type's  locking  scheme,  one  must  specify  the  protocol  by  which  each  of  the 
type's  operations  acquires  and  releases  locks.  Although  two-phase  locking  can  be  used  with  type-specific 
locks,  the  locking  protocol  may  also  ire  type-specific.  A  uniform  two-phase  protocol  is  simplest  to  understand, 
but  the  added  flexibility  of  type-specific  protocols  can  allow  increased  concurrency.  The  exact  nature  of  a 
type-specific  protocol  depends  not  only  on  die  semantics  of  the  type,  but  also  on  the  particular  representation 
and  implementation  chosen. 

6.2  Directories 

A  simple  idculi/.ed  implementation  of  the  Directory  type  specified  in  Section  4.1  illustrates  the  basics  of 
type-specific  locking.  In  this  example,  it  is  assumed  that  the  Directory  operations  have  been  implemented  in 
a  straightforward  fashion  with  no  attempt  at  internal  concurrency.  It  is  further  assumed  that  the  operations 
act  under  die  protection  of  a  monitor  or  other  mutual  exclusion  mechanism  during  the  actual  manipulation  of 
Directory  objects.  Locking  is  used  exclusively  to  control  the  sequencing  of  Directory  operations  on  behalf  of 
multiple  transactions.  The  locking  and  mutual  exclusion  mechanisms  cannot  be  completely  independent, 
however,  because  mutual  exclusion  must  be  released  when  waiting  for  a  lock  within  die  monitor,  litis  is  a 
standard  technique  in  systems  that  use  monitors  for  synchronization  [Hoare  74], 

Because  the  mapping  from  invocation  schedules  to  abstract  schedules  is  trivial  for  diis  implementation,  the 
second  step  of  the  validation  process  is  eliminated.  The  discussion  of  the  locking  scheme  for  Directories 
therefore  focuses  on  the  first  and  third  steps:  informal  characterization  of  the  set  of  legal  schedules,  and 
comparison  of  this  set  with  the  set  of  consistent  schedules. 

As  was  noted  in  Section  4,1,  the  operations  for  the  Directory  data  type  can  be  divided  into  three  groups: 

•  Modify  operations,  that  alter  the  particular  Directory  entry  identified  by  the  key  string  a. 

•  Lookup  operations,  that  observe  the  presence,  absence,  or  contents  of  the  particular  Directory 
entry  idenufied  by  the  key  string  a. 

•  Dump  operations,  that  observe  properties  of  die  Directory  that  cannot  be  isolated  to  an  individual 
entry. 

Corresponding  to  these  groups,  three  lock  classes  can  be  defined: 

•  {DirModify(<7)}:  To  indicate  that  an  incomplete  transaction  has  inserted  or  deleted  an  entry  with 
key  string  cr. 


24 


•  {l)irl.ookup(o)}:  To  indicate  llial  an  incomplete  transaction  has  attempted  to  observe  tiic  entry 
with  key  string  a. 

•  {DirDumpJ:  To  indicate  tliat  an  incomplete  transaction  has  performed  a  Dir  Dump  of  die  entire 
directory. 

T'hc  lock  compatibility  table  for  Directories  can  be  found  in  Table  1.  Since  there  arc  a  potentially  infinite 
number  of  strings,  the  symbols  a  and  a  arc  used  to  represent  two  arbitrary  non-identical  strings. 

l.ock  Held 


DirModify(o) 

l)irl.ookup(o) 

DirDump 

Lock  Rccuested  Dir.Modifvfa) 

No 

No 

No 

DirModify(a') 

OK 

OK 

No 

l)irlookup(a) 

No 

OK 

OK 

Dirl.ookup(a') 

OK 

OK 

OK 

DirDump 

No 

OK 

OK 

Table  1:  Lock  Compatibility  Table  for  Directories 

Each  entry  in  this  table  reflects  the  nature  of  one  of  the  type-specific  dependency  relations  for  Directories. 
Compatible  entries  represent  dependency  relations  in  which  cycles  arc  allowed  to  occur:  for  example,  the 
entry  in  row  2.  column  2  is  "OK"  because  cycles  are  permitted  in  the  _  M((J  (  dependency  relation. 
Incompatible  entries  reflect  proscribed  relations,  such  as  die  entry  in  row  1.  column  2,  which  is  due  to  die 
proscribed ,  ...  .relation. 

The  protocol  used  by  die  Directory  operations  for  acquiring  and  releasing  locks  is  as  follows: 

•  Dirlnscrt  or  DirDelete  operations  dial  specify  the  key  string  a  obtain  a  {DirModify(cr)}  lock  on 
the  Directory.  If  die  operation  succeeds,  die  lock  is  held  until  end-of-transaction.  If  the  operation 
fails,  die  lock  is  converted  to  a  {Dirl.ookupfo)}  lock,  which  is  held  until  end-of-transaction. 

•  DirLookup  operations  that  specify  the  key  string  a  obtain  a  {DirLookup(a)}  lock  on  die  Directory 
that  is  held  until  end-of- transaction. 

•  DirDump  operations  obtain  a  {DirDump}  lock  on  the  Directory'  that  is  held  until  end-of- 
transaction. 

The  following  example  demonstrates  how  the  components  of  the  locking  scheme  interact.  Suppose  a 
Directory  D  is  initially  empty.  If  a  transaction  T1  performs  the  operation  DirDeletc(l),  "Zebra"),  this 
operation  will  fail  by  returning  not  found  and  leave  a  {DirLookupC’Zcbra”)}  lock  on  the  Directory  until  the 
termination  of  Tr  Now  suppose  a  second  transaction,  T2,  performs  the  operation 
DirInscrt(D,  "Zebra”,  capa).  According  to  the  protocol,  Dirlnscrt  must  first  obtain  a  {DiriVIodify("Zcbra")} 
lock.  Because  the  dependency  relation  ^  is  proscribed,  this  lock  is  incompatible  with  the 
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{IViri.ookupC'Zchra")}  lock  already  held  by  Tj  (see  row  I,  column  3  of  die  compatibility  tabic).  Therefore. 
T,  will  be  blocked.  If  subsequently  becomes  blocked  while  attempting  to  access  an  object  already  locked 
by  T,.  a  deadlock  will  occur.  Both  transactions  arc  then  blocked  attempting  to  form  dependencies  that  arc 
part  of  proscribed  relations.  Although  these  relations  may  involve  different  objects,  or  even  different  types,  a 
cycle  in  the  union  of  the  two  relations  is  effectively  prevented.  This  is  exactly  the  behavior  required  to 
achieve  consistency  among  cooperative  types.  On  the  other  hand,  if  I  j  completes  successfully  the  lock  is 
released  and  the  dependency  of  T,  on  TL  is  permitted  to  form.  Since  die  I. (a)  — *  Vl(j)  dependency  cannot 
lead  to  cascading  aborts,  one  may  conclude  (after  the  fact)  that  delaying  T?  was  unnecessary. 

By  contrast,  a  transaction  Tj  that  performs  die  operation  I)irlnsert(I),  ”GiralTe",capa)  need  not  be  blocked, 
because  die  dependency  relation  is  not  proscribed.  Accordingly,  row  2,  column  3  of  the 

compatibility  table  indicates  that  a  {l)irModify(”Giraffc”)}  lock  is  compatible  with  a  {DirLookup("7.chra")} 
lock. 

Although  not  a  formal  proof,  this  example  characterizes  the  set  of  legal  schedules  permitted  by  the 
implcmcntauon.  and  shows  how  the  lock  classes,  compatibility  table,  and  locking  protocol  combine  to 
guarantee  that  the  legal  schedules  correspond  to  the  consistent  schedules  defined  in  die  last  section.  They 
capture  die  idea  that,  for  this  abstract  data  type,  synchronization  of  access  depends  on  the  operations  being 
performed,  the  particular  entries  in  die  Directory  they  attempt  to  reference,  and  their  outcome.  Because  locks 
arc  on  Directory  objects,  not  components  of  directories,  the  technique  also  handles  phantoms:  entries  that  are 
mentioned  in  operations  but  arc  not  present  in  the  Directory. 

6.3  Strictly  FIFO  Queues 

Type-specific  locking  can  also  be  used  in  implementations  of  the  Queue  data  type  of  Section  4.2.  As  in  the 
preceding  example,  assume  a  idealized  implementation  operating  under  conditions  of  mutual  exclusion.  To 
implement  striedy  FIFO  Queues  supporting  only  QEnter  and  QRemovc  operations,  two  lock  classes  arc 
sufficient:  {QEntcr(cr)}  and  {QRcmovc(cr)}.  As  in  the  case  of  Directories,  locks  on  Queues  identify  the 
parucular  entry  to  which  the  operation  requesting  the  lock  refers.  Since  Queue  entries  are  not  identified  by 
key  strings,  it  is  assumed  that  at  QF.ntcr  time,  each  clement  is  assigned  an  identifier  unique  to  the  Queue 
instance.  These  identifiers  correspond  to  those  used  in  defining  the  dependency  relations.  Thus,  a 
{QEntcr(a)}  lock  indicates  that  an  element  with  identifier  cr  has  been  entered  into  the  Queue  by  an 
incomplete  transaction.  Likewise,  a  {QRctnove(cr)}  lock  indicates  that  the  element  with  identifier  cr  has  been 
removed  form  the  Queue  by  an  incomplete  transaction. 

The  protocol  for  the  Queue  operations  is: 
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•  QEnter  operations  must  obtain  a  {Ql'  iitci(o)}  lock,  where  a  is  the  newly-assigned  identifier  for 
the  entry  to  be  added.  Tins  lock  is  held  until  end-of-transaction. 

•  QRemote  operations  must  obtain  a  {QRemovc(o)J  lock,  where  a  is  the  identifier  of  die  entry  at 
the  head  of  die  Queue.  This  lock  is  held  until  end-of-transaction.  Note  that  obtaining  a 
{QRemove(a)}  lock  does  not  necessarily  imply  that  an  entry  a  is  actually  in  die  Queue,  because 
the  transaction  that  made  the  entry  may  have  since  aborted.  If  so.  die  QReniove  operation  must 
request  a  {QRvmoic(o')}  lock  on  the  new  headmost  entry,  o'. 


Table  2  shows  die  lock  compatibility  table  for  Queues.  As  usual,  the  symbols  o  and  o'  represent  the 
identifiers  of  two  different  elements.  Because  die  element  identifiers  arc  unique,  certain  situations  (e  g. 
attempting  to  enter  an  element  with  the  same  identifier  as  an  element  already  removed)  cannot  occur.  The 
compatibility  function  is  undefined  in  these  eases,  so  die  table  entries  arc  marked  ‘NA’  for  'Not  Applicable’. 


Lock  Held 
QEnter(o) 

QRcmovc(cr) 

Lock  Reuucstcd  OEnter(a) 

NA 

NA 

QLnter(cr’) 

No 

OK 

QRemove(a) 

No 

NA 

QRetnovc(cr') 

OK 

No 

Table  2:  Lock  Compatibility  Table  for  Queues 

The  lock  compatibility  table  reflects  the  limited  concurrency  of  this  type.  Once  a  QRemove  operation  has 
retrieved  the  entry  with  identifier  <j,  some  entry  with  identifier  o’  becomes  the  head  element  of  the  Queue. 
But  other  transactions  will  be  blocked  trying  to  obtain  the  {QRcinovc(a’)}  lock  needed  to  remove  it,  until  the 
first  transaction  completes.  Multiple  QEnter  operations  on  behalf  of  different  transactions  interact  in  the 
same  way.  The  incompatibility  of  {QRcmovc(a)}  with  {QEnter(<j)}  ensures  that  an  uncommitted  entry 
cannot  be  removed  from  the  Queue,  thereby  eliminating  a  potential  cause  of  cascading  aborts. 

6.4  WQueues 

For  a  comparable  idealized  implementation  of  WQueues  supporting  only  WQEntcr  and  WQRemovc,  the 
same  lock  classes  may  be  used  as  for  FIFO  Queues.  Tire  major  difference  between  the  two  types  show's  up  in 
the  lock  compatibility  function,  given  by  Table  3.  To  reflect  the  allowability  of  interleaved  WQEnter 
operations  by  different  transactions,  the  table  entry  in  row  2,  column  2  defines  {WQEntcr(<j)}  and 
{WQEntcr(cr’)}  locks  to  be  compatible.  Similarly,  the  entry  in  row  4,  column  3  now  permits  multiple 
transactions  to  perform  WQRemovc  operations.  The  only  remaining  restriction  is  the  one  in  row  3,  column  2 
that  prevents  uncommitted  entries  from  being  removed.  This  prevents  cycles  in  the  proscribed 
dependency  relation  and,  because  the  lock  is  held  until  end-of-transaction,  also  prevents  cascading  aborts. 
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1  .ock  Held 

WQKntcr(o)  WQRemove(cr) 


!  ock  Rcuiiestcd  WQF.ntcr(a)  NA  NA 

WQKntcr(ff')  OK  OK 

WQRcmove(o)  No  NA 

\VQRc>movc(a')  OK  OK 


1'able  3:  Lock  Compatibility  Table  Tor  WQucucs 

The  locking  protocol  for  the  WQueue  operations  is  substantially  the  same  as  the  one  for  the  Queue 
operations.  The  only  difference  is  that  a  WQRemove  operation  that  is  unable  to  obtain  the  required 
{WQRcmovcla)}  lock  on  die  element  at  die  head  of  the  WQueue  docs  not  block.  Instead,  WQRemove 
searches  down  the  WQueue  for  some  other  element  with  identifier  o',  for  which  a  {WQReniovc(<j')}  lock  can 
be  obtained.  'This  reflects  the  property  of  WQucucs  that  permits  elements  farther  down  the  WQueue  to  be 
removed  when  the  head  element  is  uncommitted.  If  no  element  can  be  found,  the  operation  is  blocked  until 
an  inserting  transaction  commits. 

6.5  Summary 

The  examples  in  this  section  have  shown  how  type-specific  locking  can  be  used  for  synchronization  in 
implementations  of  several  data  types.  The  examples  show  how  locking  can  be  used  to  prevent  cycles  in 
proscribed  dependency  relations,  including  cycles  containing  several  types  of  objects.  They  also  indicate  how 
locking  can  be  used  m  prevent  cascading  aborts. 

A  full  discussion  of  the  syntax  and  implemcntadon  of  type-specific  locking  mechanisms  is  beyond  the  scope 
of  this  paper.  Further  work  is  needed  to  determine  the  specific  primitives  required  for  definition  of  new 
object  types,  locking,  unlocking,  conditional  locking,  etc.  Another  area  requiring  further  study  is  the 
relationship  between  the  locking  mechanism  and  other  synchronization  mechanisms  that  arc  used  for  mutual 
exclusion  and  to  signal  events.  It  appears,  however,  that  implementation  of  a  type-specific  locking 
mechanism  is  often  no  more  complex  or  expensive  than  implementations  of  standard  locking.  Unlike 
predicate  locking  schemes  [Eswaran  76],  the  set  of  locks  that  apply  to  a  particular  object  can  easily  be 
determined.  It  is  also  not  difficult  to  determine  what  processes  may  be  awakened  in  response  to  an  event  such 
as  transaction  completion. 


7  Summary 

This  paper  has  been  concerned  with  synchronizing  transactions  that  access  shared  abstract  types.  In  our 
model,  four  properties  distinguish  such  types  from  others: 

•  Operations  on  them  arc  permanent. 

•  They  support  failure  atomicity  of  transactions. 

•  They  do  not  permit  cascading  aborts. 

•  They  contribute  to  preserving  ordering  properties  of  groups  of  transactions. 

These  properties  arc  not  independent,  and  the  mechanisms  that  arc  used  to  achieve  them  arc  therefore  related 
as  well. 

Schedules  and  dependencies  arc  useful  in  understanding  die  interaction  between  concurrent  transactions. 
The  well-known  consistency  property  of  scriali/ability  can  be  redefined  as  a  special  ease  of  ordcrability  with 
respect  to  a  dependency  relation.  The  specific  dependency  relation  depends  on  how  much  semantic 
knowledge  is  available  concerning  operations  on  objects.  When  Read  operations  are  distinguished  from 
Write  operations,  serializability  requires  ordcrability  with  respect  to  a  less  restrictive  dependency  relation  than 
when  this  distinction  is  not  made.  Dependencies  can  also  be  used  to  characterize  schedules  that  arc  not  prone 
to  cascading  aborts. 

Additional  type-specific  semantic  knowledge  about  operations  can  allow  additional  concurrency.  The 
interleaving  specifications  for  Directories  and  Queues  developed  in  Sections  4.1  and  4.2  were  stated  in  terms 
of  ordcrability  with  respect  to  type-specific  dependencies.  To  increase  concurrency  further,  the  WQueue 
sacrifices  serializabili.y  while  preserving  ordcrability  with  respect  to  a  less  restrictive  dependency.  When 
several  abstract  types  are  combined  in  a  transaction,  ordcrability  must  be  guaranteed  with  respect  to  the 
relation  that  is  the  union  of  the  proscribed  relations  of  the  individual  types. 

Section  6  described  a  locking  mechanism  for  implementing  the  synchronization  required  by  the  types 
described  in  Section  4.  By  allowing  locks  that  consist  of  a  type-specific  lock  class  and  instance-specific  data, 
the  mechanism  provides  a  powerful  framework  for  using  type-specific  semantics  in  synchronization.  This 
mechanism  is  suitable  for  use  in  transactions  containing  multiple  types,  and  it  can  also  be  used  to  prevent 
cascading  aborts.  The  implementation  of  Directories  shows  how  type-specific  locking  permits  a  uniform 
treatment  of  the  problem  of  phantoms.  Locks  need  not  be  directly  associated  with  particular  components  of 
objects,  which  facilitates  the  separation  of  synchronization  from  other  type  representation  issues.  The 
examples  of  various  Queue  types  show  the  mechanism’s  flexibility. 
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This  paper  has  not  provided  a  complete  discussion  of  the  issues  involved  in  the  specification  and 
implementation  of  shared  abstract  types.  For  example,  we  have  not  discussed  the  construction  of  compound 
shared  abstract  types,  which  use  other  shared  abstract  types  in  their  implementation.  (However,  Schwarz 
[Schwarz  82]  gives  an  example  of  this.)  In  addition,  we  have  hardly  mentioned  recovery  considerations, 
though  we  beiieve  logging  mechanisms  as  described  by  I  .indsay  [Lindsay  79]  can  be  extended  to  meet  the 
needs  of  shared  abstract  t\  pes.  Recovery  is  discussed  more  fully  in  a  related  paper  [Schwarz  S3].  Finally,  wc 
have  not  discussed  specific  algorithms  for  coping  with  deadlocks. 

Clearly,  the  definition  and  implementation  of  shared  abstract  types  is  more  difficult  than  the  definition  and 
implementation  of  regular  abstract  types.  However,  once  these  types  arc  implemented,  programmers  can 
construct  arbitrary  transactions  that  invoke  operations  on  the  types.  These  transactions  should  greatly 
simplify  the  construction  of  reliable  distributed  systems.  Though  this  paper  has  focused  entirely  on 
synchronization,  wc  believe  that  this  topic  is  central  to  understanding  how  transactions  can  be  used  as  a  basic 
building  block  in  the  implementation  of  distributed  systems. 
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